Many applications, such as a customer relationship management (“CRM”) application or enterprise resource planning (“ERP”) application, provide a standard set of entity types with each entity type having attributes to model and manage business data. For example, a CRM application may have a standard set of entity types such as an account, a customer, and a campaign, and the account entity type may have attributes such as name and address. A data model specifies metadata that defines the entity types and attributes for the entity types for the business data. These applications may also allow users to modify the data model, for example, by defining new entity types and new attributes. For example, a user may define an entity type such as a college that has attributes that include a name and a public/private flag. Each entity type is represented as a “metadata entity” in the data model for the application and has an entity name. For example, a CRM application may have a metadata entity for each account, customer, and campaign with the names of “account,” “customer,” and “campaign.” These applications also allow system administrators or system customizers to create “entity records,” which are instances of entity types, to store the data of the applications as the values of the attributes of the entity type. For example, a user may create an entity of the customer entity type for each customer. These applications also allow users to define actions to modify data and functions to access data. For example, a user may define an action to add an entity that is a list (“list entity”) to an entity that is a campaign (“campaign entity”).
These applications may also support a client/server model in which the application is hosted on a server that interfaces with client code that runs on user devices (e.g., desktops or smart phones). These applications may allow the clients to access the server using an interface that supports the Simple Object Access Protocol (“SOAP”). SOAP is a protocol specification for exchanging structure information for web services, typically via the Hypertext Transfer Protocol (“HTTP”). A SOAP message consists of an envelope, a header, and a body. These applications typically use a request/response model to allow clients to access the services of the application by invoking operations. A request sent from a client to the server specifies the requested service, such as create a new metadata entity corresponding to a new entity type, create a new entity of a certain entity type, or perform a user-defined operation (i.e., action or function). The request also specifies parameters for the request, such as the attributes of the metadata entity to create, the entity type of the entity to create and the values of its attributes, and the parameters for an action. A response to a request is sent from the server to the requesting client and includes responsive data. For example, the responsive data for a request to create an entity may be a globally unique identifier (“GUID”) for the entity. After receiving the response, the client can then can send a request that includes the GUID to modify an attribute of the entity. A request message and the response message are referred to as a message pair. These applications, of course, need to understand and process the message pairs.
Although a separate code could be specifically developed to handle each message pair (e.g., extracting operation name and parameter values), an application may instead store information, referred to as “message pair data,” defining each message pair and using common code to process message pairs. The message pair data includes parameter information for each parameter that identifies the name of the parameter and its type (e.g., string or GUID). When a request message is received, the common code extracts the operation name from the message, retrieves the message pair data for that operation name, and then for each parameter, extracts the data for that parameter from the message and creates an actual parameter of the specified type that is initialized based on the extracted value. The common code then invokes the operation passing the actual parameters.
The following is an example of the signature for a service named “AddItemCampaign,” which adds an item (e.g., a list entity or product entity) to the campaign:
AddItemCampaign(GUID CampaignId, Guid EntityId, string EntityName)
The information defining the message pair for this service may be represented using eXtensible Markup Language (“XML”) data as follows:
<SdkMessagePair><Endpoint>soap</Endpoint><SdkMessageRequest><Name>AddItemCampaign</Name><Fields><Field><Name>CampaignId</Name><ClrParser>System.Guid</ClrParser></Field><Field><Name>EntityId</Name><ClrParser>System.Guid</ClrParser></Field><Field><Name>EntityName</Name><ClrParser>System.String</ClrParser></Field></Fields></SdkMessageRequest><SdkMessageResponse>. . .</SdkMessagePair>
The XML data includes a <field> tag for each parameter that specifies the name of each parameter (e.g., “EntityId”) and its type (e.g., System.Guid). When a message is received that specifies the AddItemCampaign operation, the server retrieves this XML data, creates the actual parameters, and invokes the AddItemCampaign operation passing the actual parameters. Although not illustrated, the XML data includes information defining the response message so that the server can send a response message with the data defined for the AddItemCampaign operation.
As discussed above, these applications provide services that allow users to define new message pairs. For example, when a user wants to define a new operation, the user installs on the server the code for the operation and a new message pair for that operation. A client can then send request messages for the new operation, and the application will use the new message pair for that operation to extract parameters and invoke the new code.
Although the usage of SOAP has been both wide spread and successful, a newer and improved protocol, referred to as the Open Data Protocol (“OData”), is being rapidly adopted by the computing industry. OData employs a Representational State Transfer (“REST”) model. A system that conforms with the REST model is said to be “RESTful.” The REST model uses the same HTTP verbs (e.g., POST and GET) as used by web browsers. For example, an OData request to retrieve a collection of people may be represented as follows:
GET serviceroot/People
The “GET” is the HTTP verb, and “serviceroot/People” is a Uniform Resource Identifier (“URI”). The “serviceroot” is the URI of the server, and “People” is a resource identifier that identifies a collection of people of the server. Upon receiving the request, the server retrieves all people entities and sends to the client the data of the people entities as the payload of the response message.
As another example, an OData request to retrieve a single instance of people may be represented as follows:
GET serviceroot/People(‘johndoe’)
The “johndoe” represents the resource identifier of the people entity to be retrieved. Both request messages and response messages can have payloads. The payloads may be specified using JavaScript Object Notation (“JSON”).
As another example, an OData message to perform an AddItemToVehicle operation on the people entity may be represented as follows:
GET serviceroot/People(‘johndoe’)/AddItemToVehicle.
The payload for the OData message may include the identifier of the vehicle. In this example, the operation AddItemToVehicle is said to be bound to the entity identified by “johndoe.” An OData request message may also include a query option for identifying entities that match a query.